Method and apparatus for test coverage analysis

ABSTRACT

A method provides for a way to test coverage data used in testing small computing platforms by assigning unique signatures to each node in the control flow graph and embedding control function calls. Signatures are embedded into the program during compilation time using the custom parser. When the program is executed the “exercised” signatures sequence is checked for correctness and used for deriving test coverage metric. This metric is used for improving unit and black-box tests. Thus, a way to collect the path-based test coverage with minimal memory and code/size impact on target system is provided.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a U.S. National Stage Application of International Application No. PCT/RU2008/000643 filed Oct. 9, 2008, which designates the United States of America. The contents of which are hereby incorporated by reference in their entirety.

TECHNICAL FIELD

The present invention relates to a method and an apparatus for test coverage analysis for testing small computer platforms like embedded systems. More specifically, the present invention is directed to a method and an apparatus for test coverage analysis having a transfer of coverage data from a target to a host computer.

BACKGROUND

Development of high integrity and mission-critical software systems requires the rigorous and efficient testing techniques. Even more challenging task is to ensure high quality requirements within embedded computing systems where different resources constraints exist. White-box testing techniques, such as code coverage analysis is, partially meet these challenges but its application is very often associated with additional load on target systems and thus achievable in far from real environments. Either it is hard to get the required thoroughness of analysis without stressing target system too much.

A lot of test coverage analysis tools already exist. Most of the already known tools in this field addressing basically the following problems:

1. Application of test coverage analysis in testing of embedded software in real environment. 2. Support of hardware with strict computing resources constraints. 3. Providing more thorough coverage metric than statement and decision coverage with reasonable efforts. 4. Achieving the higher trustworthiness of coverage data with checking of program flow correctness. 5. Semi-automatic execution of test coverage measurement.

The paper Cornett, S., Code Coverage Analysis, www.bullseye.com/coverage.html [5 Jun. 2008] gives a complete description of code coverage analysis or test coverage analysis. BullseyeCoverage tool which is proposed requires the file system functionality on target and thus cannot be used for simpler applications.

From the publication Testwell CTC++, Test Coverage Analyzer for C/C++, www.testwell.fi/ctcdesc.html [5 Jun. 2008]. A system is known which supports communication interfaces for transferring coverage data from target to host but still requires operating system functionality on target.

The Manual for CoverageMeter, Code Coverage Measurement for C/C++, CoverageMeter Software Factory, http://www.coveragemeter.com/manual.html [5 Jun. 2008] provides the state-of-the-art code coverage technique (source code analysis, instrumentation, generation of application), but still requires operating system functionality on target.

The tool suite Cantata++ v.5.2.1, Technical brief, IPL, http://www.iplbath.com/products/tools/pt400.uk.php [5 Jun. 2008], along with other testing features is capable to perform integrated coverage analysis. It declares the possible communication of results data from target to host platform by means of serial, LAN, USB, JTAG. This tool does not require file I/O on the target platform but exact significant memory resources from target.

The publication Majzik I., Pataricza A. Control Flow Checking in Multitasking Systems//Periodica Polytechnica Ser. Electrical Engineering, Vol. 39, No. 1, pp 27-36, 1995 shows a new watchdog-processor method SETS (Signature Encoded Instruction Stream) and the part of the method responsible for instrumentation is based on a Assigned Signature Scheme.

None of the listed coverage analysis tools fully addresses the problems mentioned above. First, all known tools do not provide the coverage metric reporting on decisions interaction which contains potential bugs not discovered by other coverage metrics. Program flow correctness check is not provided by these tools as well. None of the tools provides instrumentation granularity up to a program basic block.

SUMMARY

According to various embodiments, software assigned signatures are used and a database of syntactically correct software paths which are described by means of signatures tree is created. As a result, the control flow coverage data is derived and analyzed. The various embodiments can basically be seen as an enhanced source code instrumentation and a online sending and processing of signatures, when target application does not store the executed signatures and just sends it to host. In this method the coverage criterion is more thorough than statement and decision coverage since it reports on covered/uncovered paths through control flow graph. Reducing the number of paths to test is achieved by using only one level of nodes connection to check (successor-predecessor) during source code instrumentation. It makes mostly performance impact to the target application and minimizes code/data size overhead of the target code/data memory.

The main advantages are a coverage analysis for small computing systems for example with no operating system, small memory or no file and network support; a robust and comprehensive coverage criterion which considers decision interaction in program code; a program flow correctness check, which proves the obtained coverage data has been the result of correct program's behavior and a granularity of instrumentation which is configurable, so certain modules, functions or even basic blocks can be instrumented or left out of coverage analysis.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated into and constitute a part of this specification, illustrate one or more embodiments and, together with the detailed description, serve to explain the principles and implementations.

In the drawings:

FIG. 1 is a general tooling and workflow diagram;

FIG. 2 is a diagram illustrating the source code transformation phase according to various embodiments;

FIG. 3 is a diagram illustrating the target system binary code generation phase according to various embodiments;

FIG. 4 is a diagram illustrating target system execution and coverage analysis phase according to various embodiments; and

FIG. 5 is a flow diagram illustrating the control flow coverage results according to various embodiments.

DETAILED DESCRIPTION

In the Interest of clarity, not all of the routine features of the implementation described herein are shown described.

FIG. 1 is showing the basic structure according to various embodiments and depicts a block CT with steps being executed during compile time and a further block RT with further steps being executed during runtime.

Within the block CT—in other words during compile time—a block SCP for a source code parser handling the instrumentation and a block GCC for the compiling is shown.

During the compile-time part of the method an instrumented application IA and a signature tree ST is created out of a source code SC.

Within the block RT—in other words during run time—a first block ETS is shown, which stands for the execution of the instrumented application IA on the target system, and a second block CDAH stands for a coverage data analyzer on the host computer which is providing a coverage analysis visualization.

The diagram of FIG. 2 is illustrating the source code transformation phase according to various embodiments with the step P1 of preprocessing & instrumentation of the source code SC and the step CFGV of control graph visualization producing the control flow graph CFG. Herein the inserted “send signature”—commands (in bold letters) become apparent.

FIG. 3 is a diagram illustrating a target system binary code generation phase according to various embodiments. In this phase the compiler C is generating binary code TSBC on the target system out of the instrumented source code ISC and supplemental source code SSC like coverage specific communication initialization and implementation library.

FIG. 4 is a diagram illustrating a target system execution and coverage analysis phase according to various embodiments. In this phase the analyzer A is providing coverage results visualization CRV using a signatures stream SS which comes from the target system TS. The analyzer A has control flow information extracted at the instrumentation level. This is implemented by the use of a serialized control flow graph, which is given as an argument to the analyzer.

The flow diagram FIG. 5 is illustrating the control flow coverage results CFCR according to various embodiments. Preferably different colors indicate on the one hand covered links L or nodes N and on the other hand not covered possible links or nodes.

Along with graphical representation of the coverage results CR the overall statistics can be optionally shown.

Compile Time

-   1. Preprocess source files (using GNU C preprocessor). -   2. Identify basic blocks and language constructions (using source     code custom parser), put signatures and link them according to     syntactically allowable program flow.

Run Time

-   1. Run the instrumented application on the target with one or more     as required test scenarios. -   2. Download signatures of “exercised” source code from target to     host PC. -   3. Analyze sequence of “exercised” signatures: compare it with the     original signature tree and collect coverage statistics.

While the invention has been disclosed in connection with embodiments shown and described in detail, their modifications and improvements thereon will become readily apparent to those skilled in the art. Accordingly, the spirit and scope of the present invention should be limited only by the following claims. 

1. A method for conducting test coverage analysis comprising: making an enhanced source code instrumentation, wherein a instrumented code and a signature tree is generated; and sending and processing of signatures, wherein the target application just sends the executed signatures to a host system where they are used in connection with the signature tree to analyze the code coverage.
 2. The method of claim 1, wherein said making an enhanced source code instrumentation is done by signing all basic blocks and language constructions with signatures during compile time and by creating a original signature tree during compile time which describes a database of syntactically correct software paths.
 3. The method of claim 1, wherein said sending and processing of signatures is done by running the instrumented application on a target system with at least one test scenario during running time; downloading signatures of “exercised” source code from the target system to a host system during running time; and analyzing a stream of “exercised” signatures during running time by comparing it with the original signature tree and collecting coverage statistics.
 4. An apparatus for conducting test coverage analysis, comprising: A source code parser for producing a instrumented code and a signature tree; A compiler for translating the instrumented code into a according instrumented binary code for the target system; and An analyzer on a host system for receiving a signature stream from the target system and for analyzing and visualizing the code coverage with the aid of the signature tree from the source code parser.
 5. The apparatus of claim 4, wherein said source code parser is operable to make an enhanced source code instrumentation is done by signing all basic blocks and language constructions with signatures during compile time and by creating the signature tree during compile time which describes a database of syntactically correct software paths.
 6. The apparatus of claim 4, wherein the apparatus is operable to run the instrumented code on a target system with at least one test scenario during running time; to receive signatures of “exercised” source code from the target system to a host system during running time; and to analyze the received stream of “exercised” signatures during running time by comparing it with the original signature tree and collecting coverage statistics.
 7. A system for conducting test coverage analysis comprising: means for making an enhanced source code instrumentation, wherein a instrumented code and a signature tree is generated; and means for sending and processing of signatures, wherein the target application sends the executed signatures to a host system where they are used in connection with the signature tree to analyze the code coverage.
 8. The system of claim 7, wherein said means for making an enhanced source code instrumentation sign all basic blocks and language constructions with signatures during compile time and create a original signature tree during compile time which describes a database of syntactically correct software paths.
 9. The system of claim 7, wherein said means for sending and processing of signatures are operable to run the instrumented application on a target system with at least one test scenario during running time; to receive signatures of “exercised” source code from the target system to a host system during running time; and to analyze a stream of “exercised” signatures during running time by comparing it with the original signature tree and collecting coverage statistics.
 10. The system of claim 8, wherein said means for sending and processing of signatures are operable to run the instrumented application on a target system with at least one test scenario during running time; to receive signatures of “exercised” source code from the target system to a host system during running time; and to analyze a stream of “exercised” signatures during running time by comparing it with the original signature tree and collecting coverage statistics.
 11. The method of claim 2, wherein said sending and processing of signatures is done by running the instrumented application on a target system with at least one test scenario during running time; downloading signatures of “exercised” source code from the target system to a host system during running time; and analyzing a stream of “exercised” signatures during running time by comparing it with the original signature tree and collecting coverage statistics. 